👍 @yyx990803

I think searching for static replacement in templates is inconsistent:

• plain strings in template expressions will be magically converted
• plain strings in JavaScript will not.

I think this can be quite confusing. Instead, I would:

• always auto inject $styles if cssModule is used
• just use the $styles variable for binding classes in all places.

• $styles is not always needed. In most cases, we are just writing plain class name, or simple js expression in binding classes.
• Always inject $styles will enlarge file size with useless codes.
• Class name replacement is done in compile time, which provides compile time error rather than runtime.

• The API needs to be consistent and clear. Currently it feels hacky because it adds a lot of mental complexity to the usage:
  • the user now needs to be aware that the templates will go through a separate compilation process that rewrites static strings in template expressions, which is different from Vue's runtime behavior.
  • needs to be aware of edge cases like concatenated class names not supported in template expressions. This can actually be quite common e.g. :class="'button-' + type"
  • different usage when doing it inside JavaScript.
• Not sure what errors can be caught when replacing class names...

To me it's much more important to have a simple mindset when using scoped CSS.

That's right. I will remove class replacement in js expressions templates.

Add CSS modules support

Simply use CSS Modules with <style module="moduleName">.

moduleName will be injected as a computed property.

Example:

<style module="style">
  .red { color: red; }
  /*
    becomes
    ._8x_KsHmyrocTNd7akA_LL { color: red; }
  */
</style>

<script>
  export default {
    ready() {
      console.log(this.style.red)
      // => _8x_KsHmyrocTNd7akA_LL
    }
  }
</script>

<template>
  <h2 v-bind:class="style.red"></h2>
</template>

Use scoped,lang and module combined:

<style scoped lang="stylus" module="style">
.red
  color: red
</style>

@yyx990803

Do we need this actually?

If you need CSS Module support, just extract style file specifically and use css-loader to handler the styles then do this:

import classes from '/path/to/style'

export default {
    data() {
        classes
    }
}

Then, we could use classes.clazzz in the template!

So, on my opinion, this pr is unnecessary.

@JounQin

1. scoped
2. Single File Component
3. There are problems using only scoped css

@YiSiWang I think there is no need to use scoped with CSS Module nor pursue single file component so mightily which makes the component a bit more confusing. 😄

一个项目由大量组件组成，大量组件需要考虑内部样式的命名，这样 @JounQin 的方式会有些不便之处：

• 对每个需要使用 CSS Modules 的组件，都需要编写一些重复代码，比如引入一个外部样式，然后把样式设置到组件的 data 属性中
• 必须是 external css， 这和 .vue 单文件的方式不兼容，使用不方便

更倾向于 尤大 的建议( 使用 $styles )，另外对 @YiSiWang 的方法有个疑问，如果已有的某个 computed 属性与 style#module#name 相同会发生什么？

( 英语不好，打汉字不会被鄙视吧.. )

@speedornothing
注入的计算属性的名字是由<style module="xxx">决定的，也就是，由组件的维护者决定的，维护者当然也知道自己组件有哪些计算属性，因此命名冲突不是问题。

@YiSiWang why do we need to explicitly declare the injected variable name? Using a reserved key like $styles seems simpler, and also it becomes more obvious when you are using the module class names.

How about something like <style module> with $styles as default?

@yyx990803 There might be multiple <style module> tags when use external css.

Though I don't think multiple moduled <style> tags are useful, it's worse to limit only one moduled tag or mix all local classes into $style.

@YiSiWang I think we can default to $styles when the module attribute has no value. You can still use self-defined names if you need multiple style tags.

Great idea! I will work on it.

But, when use multiple no-module-value <style>s (let's call it default module), should it throw an error or mix their class names? I prefer the former.

@YiSiWang yeah, throwing an error in that case sounds fine.

@yyx990803 Docs updated.

Thanks for the great work! Btw, would you be interested in porting this to v9.x? (next branch)

@yyx990803 Yes, I'm willing to do it.

Thanks for merging and HAPPY MOON FESTIVAL!